docs: add network ip masquerade example#7075
Conversation
Signed-off-by: sanghun <vitash1215@gmail.com>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
docker-agent
left a comment
docker-agent
left a comment
There was a problem hiding this comment.
Assessment: 🟢 APPROVE
docker-agent
left a comment
docker-agent
left a comment
There was a problem hiding this comment.
Assessment: 🟢 APPROVE
docker-agent
left a comment
docker-agent
left a comment
There was a problem hiding this comment.
Assessment: 🟢 APPROVE
docker-agent
left a comment
docker-agent
left a comment
There was a problem hiding this comment.
Assessment: 🟢 APPROVE
docker-agent
left a comment
docker-agent
left a comment
There was a problem hiding this comment.
Assessment: 🟢 APPROVE
This is a clean, well-placed documentation addition. The new example correctly demonstrates the com.docker.network.bridge.enable_ip_masquerade option using the proper --opt flag syntax, consistent with the bridge driver options table immediately above it. Code fence style and indentation match the rest of the file.
The drafter raised a concern that omitting --subnet could mislead readers into creating a network with broken outbound connectivity. The verifier dismissed this: the file already uses minimal examples without --subnet elsewhere (e.g. line 44), the example demonstrates a specific option rather than providing a production-ready setup, and disabling masquerade is valid in multiple topologies (e.g. when the host is the router). No in-scope bugs were found.
|
Friendly ping 🙂 Just checking in on this one — it's a small docs-only change (adding an IP-masquerade example to @thaJeztah whenever you have a spare moment, could you take a look? No rush at all, and happy to rebase or adjust if anything's needed. Thanks! 🙏 |
| To configure IP masquerading for a custom `bridge` network, use the | ||
| `com.docker.network.bridge.enable_ip_masquerade` option. For example, to create | ||
| a custom bridge network with IP masquerading disabled: | ||
|
|
||
| ```console | ||
| $ docker network create \ | ||
| --driver bridge \ | ||
| --opt com.docker.network.bridge.enable_ip_masquerade=false \ | ||
| no-masq-network | ||
| ``` | ||
|
|
There was a problem hiding this comment.
I don't think this is the right place/format for this. We already explain the option in the table above. I think what's missing if anything is to explain how these options are set. The introduction to the section currently reads:
When creating a custom bridge network, the following additional options can be passed.
But we don't say how, i.e.
When creating a custom bridge network, you can configure driver options using the
--optflag. The following table lists all configurable driver options for bridge networks: ...
And then below the table we could have a small example showing the exact syntax:
For example, to create a custom bridge network with IP masquerading disabled:
$ docker network create \ --driver bridge \ --opt com.docker.network.bridge.enable_ip_masquerade=false \ no-masq-network
4 participants
What changed
Added a small
docker network createexample showing how to configure IP masquerading for a custombridgenetwork with--opt com.docker.network.bridge.enable_ip_masquerade=false.Why
This follows up on docker/docs#13861. The existing table maps
com.docker.network.bridge.enable_ip_masqueradeto the--ip-masqdaemon option for the defaultdocker0bridge, but it does not directly show the equivalentdocker network createcommand for a custom bridge network.Related issue status
#5599 already improved this section by clarifying that
--ip-masqis a daemon option for the defaultdocker0bridge. This PR adds a direct example for configuring the equivalent bridge driver option when creating a custom bridge network.If maintainers consider #5599 sufficient for docker/docs#13861, then the issue may only need a status decision rather than this follow-up change.
Validation
make -f docker.Makefile mddocsmake -f docker.Makefile yamldocsgit diff --checkNotes
This is a documentation-only change. It does not change Docker CLI or daemon behavior.